fix(fields): lookup multi-value hydration batches via $in and shows loading instead of the empty placeholder (#3108) - #3120
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
…oading instead of the empty placeholder (#3108) A multi-value lookup hydrated its committed ids with a SERIAL findOne per id — 41 selected users meant 41 sequential round-trips, and for those seconds the trigger rendered the bare "Select…" placeholder, indistinguishable from having no value at all (downstream users read a populated field as empty and could clear it by hand). - Several unresolved ids now hydrate with one `$in` query per LOOKUP_PAGE_SIZE chunk (chunks in parallel); the single-id case keeps the pre-existing cheap paths (primary-id findOne GET / equality filter for id_field, #3508). - While any committed bare id is still unresolved, the trigger (and the readonly renderer) shows a spinner + "N selected" instead of the empty placeholder. A settled-set keeps the spinner from sticking forever on ids that will never resolve (deleted records, fetch failures) — those fall back to the pre-existing drop behaviour. The committed value itself is never rewritten during hydration (handleSelect/handleRemove operate on the raw value), so submitting mid-hydration was already lossless; the loading state removes the visual lie that invited manual clearing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #3108.
Problem
A multi-value lookup hydrated its committed ids with a serial
findOneper id — 41 selected users meant 41 sequential HTTP round-trips. For those seconds the trigger rendered the bare "Select…" placeholder, indistinguishable from having no value at all: downstream users (os-project-titanwind-ehr#670) read a populated field as empty, and could clear real data by hand.Fix (
packages/fields/src/widgets/LookupField.tsx)$filter: { [idField]: { $in: chunk } }query perLOOKUP_PAGE_SIZEchunk, chunks in parallel. The single-id case keeps the pre-existing cheap paths (primary-idfindOneGET, equality filter for a non-primaryid_field— #3508 behaviour preserved).table.selected/lookup.loading); no new translations.On issue point 3 (guarding against submit clearing values): the component never rewrites
valuefrom resolved options —handleSelect/handleRemoveoperate on the raw committed array — so mid-hydration submits were already lossless; the loading state removes the visual lie that invited manual clearing.Verification
LookupField.hydration.test.tsx(5 cases: one batched$inround-trip, in-flight count+spinner with no placeholder, failure settles, readonly loading, single-idfindOnekept) + existing idField/dependsOn suites — 13/13 green.field_zoo.f_lookupsrecord with 41 selected accounts hydrates via a singleGET /api/v1/data/showcase_account?top=41&filter=["id","in",[…41 ids…]]; with simulated slow network the edit modal shows spinner + "已选择 41 项" during hydration (never "选择…"), all 41 chips render after, and the stored value stays 41 ids across repeated open/close.Pure bug fix — no changeset per AGENTS.md.
🤖 Generated with Claude Code